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project's  software  development  environment.  The  second  form  is  the  Component 
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nent  data  may  be  collected  at  several  levels  such  as  a  System,  Functional  Group, 
and  Module.  In  general,  the  forms  have  been  designed  to  identify  key  data 
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DACS  DATA  COLLECTION  PRODUCTIVITY  FORMS 


Introduction 

DACS  has  designed  two  data  collection  forms  for  software 
life-cycle  productivity-related  data.  The  first  form,  the 
Project  Summary  Form,  describes  a  project's  software  development 
environment.  The  second  form  is  the  Component  Summary  and 
describes  the  software  components  of  a  project,  resources  expended 
during  its  development,  and  any  noted  discrepancies.  Component 
data  may  be  collected  at  several  levels  such  as  System,  Functional 
Group,  and  Module.  Figure  1  describes  the  general  attributes  and 
relationships  of  each  component  level.  In  general,  the  forms 
have  been  designed  to  identify  key  data  collection  areas  yet  be 
flexible  enough  to  accommodate  additional  project-specific  data. 

Project  Summary  Form 

This  form  is  used  to  collect  data  concerning  (i)  the  general 
nature  of  the  project,  (2)  the  project  priorities  and  constraints, 
and  (3)  the  software  development  technologies  used  in  the  project. 

The  data  elements  of  project  name,  project  type,  project  description, 
ntmber  of  systems,  number  of  functional  groups,  number  of  modules 
and  standards  record  the  general  nature  of  the  project.  Priorities 
and  constraints  may  be  chosen  from  several  common  ones  listed  on 
the  form,  or  project-specific  entries  may  be  noted.  A  list  of 
software  development  technologies  is  also  provided  to  which  the 
project  may  add  entries. 

Component  Summary  Form 

This  form  is  used  to  collect  data  concerning  (1)  the  software 
engineering  characteristics  of  the  component,  (2)  the  resources 
expended  throughout  the  life  cycle  of  the  component  and  (3)  the 
discrepancies  detected  in  the  component's  life  cycle.  Complexity, 
type,  description,  size,  programming  language,  and  mode  of  construc¬ 
tion  describe  the  component  in  software  engineering  terms.  The 
resources  expended  on  the  component  arfi  recorded  by  life-cycle 
phase  and  time  in  terms  of  person-hours  and  computer-hours.  The 
nxsnber  of  discrepancies  found  in  the  component  are  recorded  by 
life-cycle  phase. 

Purpose 

The  purpose  of  these  forms  is  to  collect  project  and  component 
level  data  that  is  common  to  most  software  development  projects.  If 
these  forms  are  to  be  used  as  a  tool  for  collecting  data  for  a  specific 
quantitative  software  engineering  model  or  method,  additional  project- 
specific  forms  should  be  developed.  To  develop  these  special  forms , 

DACS  Software  Engineering  Research  Review  -  Quantitative  Software  Models. 
SRR-1,  should  be  used  to  determine  the  data  parameters  to  be  collected 
for  the  specific  application. 
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The  purpose  of  the  project  summary  form  is  to  describe  the  project  develop¬ 
ment  environment  as  the  project  evolves  through  the  software  life-cycle.  It  should 
be  completed  by  the  project  manager  at  the  beginning  of  the  project,  at  each  major 
milestone,  and  at  the  end.  Data  at  the  initiation  of  the  project  are  estimated; 
intermediate  reports  should  change  estimates  to  actuals  and  update  estimates,  and 
the  final  report  should  describe  the  actual  project  environment. 


DEFINITIONS 


Explanations  and  definitions  of  the  form's  data  elements  are  presented  below. 

1.  Reporting  Period  -  Indicate  the  time  period  (start  and  end  date)  and  life-cycle 
phase. 

2.  Project  Name  -  Name  of  the  project. 

3.  Description  -  An  overview  of  the  mission  of  the  project. 

4.  Project  Duration  -  Total  length  of  the  project  in  months. 

5.  Number  of  Systems  -  A  system  is  a  software  component  that  provides  a  meaning¬ 
ful  product  to  the  user  and  is  usually  capable  of  operating  Independently  of 
other  systems.  Indicate  the  number  of  systems  in  the  project  software. 

6.  Number  of  Fxmctional  Groups  -  A  functional  group  is  a  software  component  that 
satisfies  a  set  of  functional  and  performance  specifications.  Indicate  the 
number  of  functional  groups  in  the  project  software. 

7.  Number  of  Modules  -  A  module  is  a  software  component  that  exists  as  a  discrete, 
identifiable  set  of  instructions.  Indicate  the  number  of  modules  in  the 
project  software. 

8.  Contact  -  Person  completing  the  form. 

9.  Developer  -  Name  of  the  organization  responsible  for  delivery  of  the  project. 

10.  Staff  Size  -  List  the  number  of  persons  assigned  to  the  project.  Include 
administrative,  technical  and  clerical  personnel. 

11.  Contract  -  Contract  number. 

12.  Managemsot  Organization  -  A  short  description  of  the  project's  management 
structure. 
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13.  Cost  Reporting  Standards  -  Standards,  specifications  or  methods  used  to  report 
project  costs. 

14.  Technical  Standards  -  Standards,  specifications  or  other  requirements  related 
to  the  technical  aspects  of  the  project  such  as  requirement  specification, 
coding,  testing,  documentation,  configuration  management  and  quality  assurance. 

15.  Constraints  -  Note  the  constraints  applicable  to  the  project.  Constraints 
not  listed  may  be  added. 

16.  Computers  -  List  the  hardware  and  operating  system  configurations  of  the 
development  computer  (system  on  which  the  software  was  developed)  and  the 
target  computer  (system  for  which  Che  software  was  developed).  Also,  list 
the  type  of  access  to  each  computer  (e.g.,  batch,  remote  batch). 

17.  Documentation  -  Delivered  pages  of  documentation.  Includes  program  listings, 
flow  charts  (low  and  hl-level) ,  operating  procedures,  maintenance  procedures 
and  any  other  descriptive  material  covering  the  design,  development,  test, 
operation,  installation  and  maintenance  of  Che  software. 

18.  Priorities  -  Note  the  priorities  applicable  to  the  project.  Priorities  not 
listed  may  be  added. 

19.  Technology  -  Note  the  software  engineering  technologies  and  techniques  applica¬ 
ble  Co  the  project.  Technologies  not  listed  may.be  added.  Attachment  1  defines 
Che  listed  technologies. 

X  Utilisation  -  Percent  of  the  total  lines  of  source  code  developed  using  this 
technology. 

20.  Support  Software  Developed  by  Project  -  List  the  software  that  was  developed 
by  Che  project  to  specifically  support  the  development  of  Che  project  deliver¬ 
able  software.  Software  In  this  category  varies  widely  but  typically  Includes 
test  generators,  test  stubs,  test  drivers,  assemblers,  compilers,  and  simulators. 

*  Parameter  common  Co  both  KADC  Productivity  Database  and  NASA-SEL  Database. 

t  Parameter  necessary  for  RADC  Productivity  Database  only. 
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(  ;  Process  Design  Language  k  )  Lrltical  Piece  First  V  }  Code  Standards  Audlto: 

(  )  Structure  Charts  (  )  Database  Analyzer  (  )  Consistency  Checker 

(  )  Top-Down  Development  (  )  Data  Dictionary  (  )  Independent  Test  Team 

(  )  Modular  Decomposition  (  )  Documentation  Generator  _  (  )  Program  Flow  Analyzer 


DACS  DATA  COLLECTION  FORM 


COMPONENT  SUMMARY 


INSTRUCTIONS 


The  purpose  of  the  component  summary  form  Is  to  describe  the  component's 
structure,  resources  used  during  Its  life  cycle  and  problems  reported  during  Its 
life  cycle.  The  form  should  be  filled  out  for  each  component  at  the  completion 
of  each  phase  by  the  person  responsible  for  components.  The  summary  may  be  used 
for  the  module,  functional  group,  and  system  component  levels. 


DEFINITIONS 

Explanations  and  definitions  of  the  form's  data  elements  are  presented  below. 

1.  Reporting  Period  -  Indicate  the  time  period  (start  and  end  date)  and  life-cycle 
phase. 

2.  Component  Name  -  Name  of  the  component. 

3.  Component  Type  -  System,  functional  group  or  module.  A  system  Is  a  software 
component  that  provides  a  meaningful  product  to  the  user  and  Is  usually 
capable  of  operating  Independently  of  other  systems.  A  functional  group  Is  a 
software  component  that  satisfies  a  set  of  functional  and  performance  specifi¬ 
cations.  A  module  Is  a  software  component  that  exists  as  a  discrete,  identi¬ 
fiable  set  of  Instructions.  (See  Figure  1  for  the  hierarchical  relationships 
between  the  components.) 

A,  Description  -  An  overview  of  the  component.  Including  its  purpose. 

5.  Contact  -  Person  completing  the  form. 

6.  Mode  of  Construction  -  List  the  modes  of  construction  for  the  component. 

Modular  -  Components  are  constinicted  such  that  each  component  has  single 
entry  and  exit  points  and  a  single  purpose. 

Unstructured  -  The  type  of  programming  constructs  Is  not  limited  to  a 
specific  set.  (See  Structured). 

Top-Down  -  The  component  Is  constructed  by  Identifying  major  functions  to  be 
accomplished  and  then  proceeds  from  there  to  an  Identification  of  the  detail 
functions  that  derive  from  the  major  ones. 

Structured  -  The  component  Is  constructed  using  a  limited  set  of  programming 
constructs.  (E.g.,  SEttUENCE*  DOUHILE.  DOUNTIL.  CASE.  IFTHENELSE.) 

Convent  loin  al  -  Structured  and/or  top-down  constructions  are  not  used. 
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Progranunlng  Language  -  List  the  programming  languages  used  for  the  component 
and  the  percent  utilization  of  each.  Base  the  percent  utilization  on  the 
number  of  lines  of  source  code. 

Component  Complexity  - 

Subjective  -  Rate  the  subjective  complexity  of  the  module  as  easy,  moderate,  or 
difficult. 

Calculated  -  List  any  calculated  complexity  metrics  (e.g.,  number  of  declslon- 
to-declslon  paths)  that  have  been  determined  for  the  component. 

Component  Size  -  Categorize  the  component  Into  new  code  (developed  for  this 
application)  and  reused  code  (developed  for  another  application  but  used  In 
this  application)  and  Indicate  its  size  by  source  Instructions  (number  of 
source  code  llne^ft  Including  comments)  and  object  words  (computer  words). 

Resources  -  List  the  person-hours  (divided  Into  technical  and  administrative 
tasks)  and  computer-hours  expended  In  development  of  the  component  for  each 
of  the  life-cycle  phases  listed  below. 


Phase 


Description 


Sa 


Conceptual 


Requirements 


Design 


Implement at  Ion 


Operation 


Defining  the  problem  statement  preliminary  systems 
analysis  and  Identifying  alternative  solution 
strategies. 

Producing  statement  of  project  objectives,  system 
functional  specifications  and  design  constraints. 

Generalizing  software  component  definitions.  Inter¬ 
faces  and  data  definitions;  verifying  these  against 
requirements. 

Generating  program  code,  testing  code,  and  documenting 
the  system. 

Integrating  software  components  and  performing  system 
acceptance  tests. 

Using  and  maintaining  the  system. 


Reported  Problems  -  List  the  number  of  problems  reported  in  the  component  during 
the  life-cycle  phases  and  the  method  used  to  detect  the  problem.  For  example, 
a  typical  detection  method  used  during  the  design  phase  Is  the  formal  design 
review;  for  the  test  phase  the  detection  method  might  be  the  system  Integration 
test. 
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Reporting  Nrlod: _  Contact: 
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PROVIDES  A  SOLUTION  TO 
A  PROBLEH 


PROJECT 
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SYSTEn 


PROVIDES  HEANINGFUL 
PRODUCT  TO  USER.  USUALLY 
CAPABLE  OF  OPERATING 
INDEPENDENTLY  OF  OTHER 
SYSTEHS 


COnPONENTS  / 


FUNCTIONAL  GROUP . . . . . S AT  I SF I ES  A  SET  OF 
A  FUNCTIONAL  AND  PERFORHANCE 

'  SPECIFICATIONS 


S 


nODULE 


A  DISCRETE  IDENTIFIABLE 
SET  OF  INSTRUCTIONS 


Figure  1.  Project-Component  Attributes  and  Relationships 


APPENDIX  1 


TECHNOLOGY  DEFINITIONS 


1.  Chief  Programmer  Team  -  A  chief  programmer  team  is  a  structured  team  of 
specialists  for  software  development  headed  by  a  chief  programmer.  The 
team  has  at  its  core  three  members:  the  chief  programmer,  the  back-up 
programmer  and  the  secretary/ librarian.  The  rest  of  the  team  consists  of 
programmers  as  required.  The  team  is  normally  limited  to  less  than  ten 
members. 

2.  Automated  Design  Tools  -  Computer  programs  used  to  provide  an  understands'  ’e 
representation  of  the  software  design  as  it  evolves. 

3.  Autonated  Requirements  Tools  -  Computer  programs  which  are  used  to  provii 
succinct  and  unambiguous  specification  of  the  system  based  on  computer  n  re- 
ments. 


4.  HIPO  Design  Aides  -  A  graphical  technique  that  defines  each  system  compon....). 
by  the  transformation  of  its  input  datasets  to  its  output  datasets  and  also 
defines  the  hierarchical  relationships  between  components. 

5.  Process  Design  Language  -  A  formal  algorithmic  specification  of  a  software 
component. 

6.  Structure  Charts  -  A  graphical  technique  which  Illustrates  the  relationships 
between  the  components  of  a  software  system. 

7.  Top-Down  Development  -  A  software  development  approach  that  Identifies  major 
functions  to  be  accomplished,  then  proceeds  from  there  to  an  Identification  of 
the  lesser  functions  that  derive  from  the  major  ones. 

8.  Modular  Decomposition  -  The  process  of  breaking  a  large  program  into  small 
modules  that  perform  complete  functions. 

9.  Program  Support  Library  -  A  software  system  which  provides  tools  to  organize, 
implement  and  control  software  development. 

10.  Simulation  -  A  computer  program  that  provides  the  target  system  with  Inputs 
or  responses  that  resemble  those  that  have  been  provided  by  the  process  for 
the  device  being  simulated. 


11. 


Structured  Programming  -  The  activity  of  programming  with  a  limited  set  of 
program  constructs. 


12.  Walk- throughs  -  A  formal  meeting  by  various  numbers  of  a  project  for  the 

review  of  source  code  and  design  for  technical  adequacy  and  error  detection. 


13.  Critical  Piece  First  -  The  implementation  of  the  most  critical  aspects  of  the 

system  first. 


lA.  Database  Analyzer  -  A  computer  program  that  reports  information  on  every  usage 
of  data,  identifies  each  program  using  any  data  elements  and  indicates  whether 
the  program  inputs,  uses,  modifies  or  outputs  the  data  element.: 
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15.  Data  Dictionary  -  A  listing  of  the  names,  lengths  and  representations  of  all 
data  items  used  in  a  software  system.  This  tool  may  be  manual  or  automated. 

16.  Documentation  Generator  -  A  computer  program  used  to  show  in  detail  the  logical 
structure  of  a  computer  program,  usually  by  producing  flowcharts. 

17.  High  Order  Language  -  A  full  repertoire  of  programming  instructions  and  state¬ 
ments  having  formal  syntax  and  lexical  rules,  usable  in  composing  machine- 
independent  source  programs. 

18.  Pre-compiler  -  A  computer  program  used  to  add  capabilities  to  a  system,  as 
implemented  by  a  language  processor,  that  provides  special-purpose  features 
not  normally  Included  as  part  of  its  input. 

19.  Reusable  Code  -  Source  code  originally  developed  for  another  application  that 
can  be  used  for  a  different  application. 

20.  Correctness  Proofs  -  The  technique  of  proving  mathematically  that  a  program 
is  consistent  with  a  set  of  specifications. 

21.  Code  Standards  Auditor  -  A  computer  program  used  to  automatically  determine 
whether  prescribed  programming  standards  and  practices  have  been  followed. 

22.  Consistency  Checker  -  A  computer  program  used  to  determine  (1)  if  requirements 
and/or  designs  specified  for  computer  programs  are  consistent  with  each  other 
and  (2)  if  they  are  complete. 

23.  Independent  Test  Team  -  A  project  group  not  associated  with  the  software  design/ 
development  section  which  is  responsible  for  testing  software  to  check  i.:s 
compliance  to  specifications. 

24.  Program  Flow  Analyzer  -  A  computer  program  that  provides  statistics  on  source 
code  statement  usage  and  timing  data  on  program  elements  during  test  case 
executions. 


